Fundamentals of Software Architecture - Part III. Techniques and Soft Skills - 19. Architecture Decisions
Part III. Techniques and Soft Skills
良いアーキテクトは、アーキテクチャを理解するだけでなく、開発チームをリードし、アーキテクチャを導入するためにステークホルダーと適切にコミュニケーションする必要がある
この章では良いアーキテクトになるために必要なテクニック、ソフトスキルについて説明していく
Architecture Decisions
アーキテクチャを決定する手順にはいかが含まれる
十分な情報収集
選択の正当化
ドキュメント化
適切にステークホルダーとコミュニケーション
アンチパターン
Covering Your Assets
間違った選択を恐れてアーキテクチャの決定を回避または延期すること
克服するには
検証に十分な情報が得られるまで待つ
開発チームを停滞させたり Analysis Paralysis アンチパターンに陥るほどは待たない
開発チームと継続的にコミュニケーションして期待通りに実装できるようにする
密に連携し、問題が起きても迅速に対応する
例: 製品データを利用するすべてのサービスインスタンスに read only のキャッシュを置く、という決定をした
サービス間呼び出しを使わずにデータを効果的に共有するため
一部のサービスでメモリが想定よりも多く必要なことがわかった
密に連携していることでこの問題をすぐに認識し、アーキテクチャを調整する
Groundhog Day
十分な選定理由が残されていなくわからないので、何度も何度も議論され続けること
技術/ビジネス両方の選定理由を残すことが重要
例: サービスごとに利用するリソースを分割し、個別にメンテ、スケールできるようにするため、モノリスをマイクロサービスに分離した
ビジネス面の選定理由が欠けている
なぜこのアーキテクチャのリファクタリングにお金を払う必要があるのか
例えば、新しい機能をより迅速に提供して市場投入までの時間を短縮する、新機能開発とリリースに関するコストを削減する
最も一般的なビジネス面の理由
コスト
市場投入までの時間
ユーザーの満足度
戦略的位置づけ
ビジネスのステークホルダーが何を重要としているのか、コミュニケーションを取ること
ebiken.icon これあるな。ドキュメントが残ってない機能の背景を考える -> またドキュメントを十分に残さない -> また数カ月後に同じような議論をしている
Email-Driven Architecture
アーキテクチャの決定が行われたことを知らない、忘れられていて実装ができない
アーキテクチャの決定の通知をメール(Slack とかチャットツール)でやらない
wiki に残す
アーキテクチャの決定を必要な人のみに通知する
ebiken.icon アーキテクトと実装者の距離が遠い、アーキテクトに対して実装者の数がかなり多いような、かなり大きな企業を想定していそう
Architecturally Significant
多くのアーキテクトは、特定技術を採用することは、アーキテクチャではなく技術的な決定だと考えている
しかし、特定のアーキテクチャ特性を直接サポートしているために技術を選定した場合はアーキテクチャの決定である
ebiken.icon スケーラビリティ(シャーディングいらない)のために Spanner 選ぶとかね
Release It! の著者 Michael Nygard によると、アーキテクチャ上重要な決定とは
構造
アーキテクチャのパターン
例: マイクロサービスでどうデータを共有するか
非機能特性
システムにとって重要なアーキテクチャ特性 (= ilities)
依存関係
コンポーネントやサービス間の結合ポイント
インターフェース
各サービスにアクセスする方法(gateway, api proxy, hub, bass)
構築手法
framework, tool, process の決定。アーキテクチャの決定に影響を及ぼすことがある
Architecture Decision Records (ADR)
ドキュメント化する効果的な方法
Michael Nygard によって布教された
特定のアーキテクチャの決定を説明する短いテキストファイル (1~2ページ程度)
ADR Tool と呼ばれるOSSも作成した
https://gyazo.com/6bcc158c0512be6331c69278db3f37bd
Title
アーキテクチャの決定を簡潔に
Status
Proposed: 上位レベルの意思決定者に承認される必要がある
Accepted: 承認され、実装の準備ができている
Superseded: 決定が変更され別のADRに
どのような決定が行われたか、なぜ変更されたかを履歴として残しておく
Draft を用意したい場合、RFC という status を作って期限を設定する
この項目を用意することで、アーキテクトが上司またはリードアーキテクトと必要なコミュニケーションを行うことを強制する
コスト
推定の実装時間に FTE 率を掛けて見積もる
フルタイム勤務のスタッフが処理できる仕事を 1とする
PO や PjM はFTEの金額を知っているので、金額を算出できる
これに基準を設けることで、決定をスムーズにする (xx円以上はより上位の承認が必要、など)
チーム間の影響
セキュリティ
Context
状況の説明
可能な代替案
Decision
なぜこの決定を行うか、その決定の正当性
あとから見た人が問題のコンテキストをよく理解するのに役立つ
問題を引き起こす可能性のある別のソリューションにリファクタすることを防ぐ
例: gRPC を通信手段として採用
理由を理解せずに別のアーキテクトが別のソリューションに書き換え
-> レイテンシが大幅に増加し、タイムアウトが多発
Consequences
全体的な影響について(メリット, デメリット)
トレードオフを言語化する
例: 非同期メッセージングにすることで、ユーザーへのレスポンスが向上したがエラー処理が複雑になる
Compliance
標準セクションではないが、追加することを推奨
アーキテクチャがちゃんと適用されていることをどうやって測定するか
コンプライアンスチェックを手動で行う必要があるのか、適応度関数を利用して自動化できるのか
テストの実行方法など
例:
https://gyazo.com/8ff2d49bf3d5a1448bcb9e0cb6ca0865
code:java
@Test
public void shared_services_should_reside_in_services_layer() {
classes().that().areAnnotatedWith(SharedService.class)
.should().resideInAPackage("..services..")
.because("All shared services classes used by business " +
"objects in the business layer should reside in the services " +
"layer to isolate and contain shared logic")
.check(myClasses);
}
レイヤの依存が正しいことをテストする
Notes
Author
Approval date
Approved by
Superseded date
Last modified date
Modified by
Last modification
ebiken.icon 普段、アーキテクチャの決定の経緯をどういう形で残しているか気になる
Confluence に残している
ebiken.icon 個人的に意識しているところ
要件
ビジネス要件
スケジュール、かけられる工数
技術的要件 (機能)
特にエッジケース
複数サービスが連携するものだったら、各サービスのエラーが起きたときどうなるか
整合性
どう復旧するか
非機能要件
リクエスト数
レコード数
コンテクスト
なぜ必要なのか
他の機能で代替できないか
代替案
それぞれ pros/cons
選定理由
コミュニケーション履歴
slack, github, jira, ..
用語の定義
が、特にフォーマットは用意していないので人によって精度が異なってる状態
人によっては書いてないことも..
Storing ADRs
どこに保存するか
一部のアーキテクトはソースコードとともに Git リポジトリに格納するが注意が必要
見れない人がいる可能性があるので、wiki など広く見れる場所のほうが適切かもしれない
例
https://gyazo.com/63f2290b3c522f93f94caae527fd6a79
ADRs as Documentation
ドキュメント化は常に難しい。ADR は良いソリューション
Decision セクション
トレードオフについて記載
Using ADRs for Standards
標準化を進め、導入するにもADRは良い
Decision セクション
標準規格が存在する必要がある理由を示す
Example
Going, Going, Gone. の例
https://gyazo.com/0c7548bb076afced983aef6caa5d18f0
https://gyazo.com/90a5e86d1197553ad1315d91e8795d66
bid = 入札
arb = architecture review board
Software Engineering at Google
優れたドキュメンテーションには一般に 3 つの側面がある。完全性、正確性、明確性だ。同じド キュメント内で 3 つ全てを得られることは稀である。例えば、ドキュメントをより「完全」にしよう とするにつれて、明確性が犠牲になり始める可能性がある。A P I のありうるユースケースを全てド キュメント化しようとすると、理解不能な混乱に陥りかねない。プログラミング言語については、 あらゆる場合に完全に正確を期する(そして起こりうる副作用を全てドキュメント化する)と、明 確性に影響することがある。その他のドキュメントについては、複雑なトピックに関して明確にし ようとすると、ドキュメントの正確性に微妙に影響する場合がある。例えば概念的ドキュメントで は、ドキュメントの主眼はあくまで読者が A P I 利用に習熟することであって、意図された全挙動の 教条主義的な概観を提供することではない。したがって、いくつかの稀な副作用は無視するよう決 めてもよい。